home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 7873 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.7 KB
  1. Path: quadostimpy.natinst.com!user
  2. From: rcauvin@natinst.com (Roger L. Cauvin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Pure Virtual Destructor Question
  5. Date: 19 Feb 1996 14:58:26 GMT
  6. Organization: National Instruments
  7. Message-ID: <rcauvin-0802960903220001@quadostimpy.natinst.com>
  8. References: <4fas7a$7ns@comet2.magicnet.net> <4fecq0$k4e@news4.digex.net> <rcauvin-0902960901140001@quadostimpy.natinst.com> <4fp5r2$dm2@news4.digex.net> <rcauvin-0602960913040001@quadostimpy.natinst.com> <4fqmp5$pbi@stc06.ctd.ornl.gov> <4g8cds$7do@news4.digex.net>
  9. NNTP-Posting-Host: quadostimpy.natinst.com
  10.  
  11. In article <4g8cds$7do@news4.digex.net>, ell@access4.digex.net (Ell) wrote:
  12.  
  13. > : > All that abstractness
  14. > : > implies is that it is not appropriate to instantiate an object of the
  15. > : > class directly, since the class is incompletely defined.  
  16. > 
  17. > I'll stick with the ARM and DWP on this one.
  18.  
  19. ...
  20.  
  21. > Again, I'll stick with the ARM and DWP on what is or isn't an "abstract 
  22. > class".
  23.  
  24. It doesn't matter.  Either way you're wrong.
  25.  
  26. Assuming the conceptual definition of "abstract class", there is no
  27. inconsistency between the C++ programming language's treatment of pure
  28. virtual destructors and other pure virtual member functions.  In either
  29. case, a class may conceptually be abstract in the sense that it is not
  30. intended to be instantiated.
  31.  
  32. Assuming the ARM and DWP definition of "abstract class", there is still no
  33. inconsistency between the C++ programming language's treatment of pure
  34. virtual destructors and other pure virtual member functions.  Both
  35. destructors and other member functions may be declared virtual and provide
  36. implementations (whether complete or not).
  37.  
  38.  
  39. Roger
  40.  
  41. ---
  42.  
  43. Roger L. Cauvin
  44. rcauvin@natinst.com
  45. Software Engineer
  46. National Instruments
  47.